Merchant ordering system using optical machine readable image representation of invoice information

ABSTRACT

A system and method for assisting ordering and payment processing of an order invoice associated with a product selected by a customer. The system comprises collecting product data about the product and generates the order invoice information for use by at least an accounting system of the merchant. The system receives symbology information in an aggregated barcode associated with the order invoice, the symbology information including at least a portion of the order invoice information encoded using a coding scheme of a barcode. The system provides an image of the aggregated barcode to the customer for use in generating a transaction request for settlement of the order invoice, and receives a transaction response indicating transaction approval or transaction denial of the order invoice.

FIELD

The present invention is related to merchant product ordering systemsusing optical machine readable images such as barcodes to expediteinvoicing.

BACKGROUND

Barcodes and other optical machine readable images are used extensivelyto represent information about an object. Decoding or reading a barcodeis accomplished by translating the patterns of the barcode, such as barsand spaces in linear barcodes or blocks or other features in a 2Dbarcode, into the corresponding numbers or characters. Barcodes arewidely used for encoding information and tracking purposes in retail,shipping and industrial settings. Barcodes and their uses are becomingmore mainstream, however their uses remain mostly in providing staticinformation about a particular product or service, or in recent yearsproviding a static link to a website in relation to the product orservice associated with the barcode.

For years, the merchant ordering and payment systems, and banking andpayment processing in general, have been trying to engineer atransaction processing technology that is secure, efficient and easy touse, thereby facilitating the customers shopping and payment experience,both at point of sale (POS) terminals and for online shopping. Inparticular, providing the customer with some control in how theirpersonal financial information is provided to the merchant has so farbeen elusive. This inability to involve more customer control of thetransaction while at the same time streamlining the amount of time andinformation a customer must spend and provide during the productordering and purchasing process has effectively relegated customerexperience in product purchasing to that of yesterday rather than thefuture. In particular, the leveraging of current and future mobiletechnology capabilities to the product transaction market topredominantly the purchase of downloadable items such as ringtones andmusic. Barcodes have been used in an effort to speed up the customerexperience by providing merchant terminals information about the productwhen scanned through a checkout scanner, i.e. the price and briefdescription of the product that the barcode is attached/applied to.However, any use of the barcode during the customer shopping experience,other than as a look up service for a price of a product on a product byproduct basis, is simply not available.

At the same time, developments in the field of mobile commerce are beingfacilitated by improved functionality and features available on mobiledevices, and by such functionality and features becoming morecommonplace on current mobile devices. For example, cell phones, smartphones and tablet computers nowadays are commonly integrated,multi-functional devices. In addition to their core, basicfunctionality, they will often have, or can be configured to have,web-enabled functionality, various other communication capabilities(e.g., e-mail, text, wi-fi, etc.), camera functions, scanning andgraphical image handling functionalities and other capabilities.Graphical interfaces of desktop computers have also become more advancedin their functionality and provided features. However, to date thecustomer shopping experience during checkout (either in person oronline) has not benefited from these advanced functionality and providedfeatures of desktop GUIs and mobile devices.

SUMMARY

Presently there is a need to provide a system and method to integratethe use of optical machine readable images in bettering the customerordering and purchasing experience that addresses at least one of theidentified problems in the current state of the art.

Currently, providing the customer with some control in how theirpersonal financial information is provided to the merchant has so farbeen elusive. This inability to involve more customer control of thetransaction while at the same time streamlining the amount of time andinformation a customer must spend and provide during the productordering and purchasing process has effectively relegated customerexperience in product purchasing to that of yesterday rather than thefuture. Contrary to current systems there is provided a system andmethod for assisting ordering and payment processing of an order invoiceassociated with a product selected by a customer. The system comprisescollecting product data about the product including a product price,merchant data including merchant identification for use in identifyingmerchant financial account information by the transaction processingsystem. The system generates the order invoice information including theproduct data, the merchant data, a total invoice amount for payment bythe customer and an invoice identification for use by at least anaccounting system of the merchant. The system receives symbologyinformation in an aggregated barcode associated with the order invoice,the symbology information including at least a portion of the orderinvoice information encoded using a coding scheme of a barcode. Thesystem provides an image of the aggregated barcode to the customer foruse in generating a transaction request for settlement of the orderinvoice, and receives a transaction response, the transaction responseincluding processing details of the transaction request by theprocessing system, the transaction response indicating transactionapproval or transaction denial of the order invoice.

A first aspect provided is a system including an order interface forassisting ordering and payment processing of an order invoice associatedwith a product selected by a customer, the order interface coupled to atransaction processing system over a communications network, the systemcomprising: a computer processor coupled to a memory, wherein thecomputer processor is programmed to assemble order invoice informationpertaining to the product and provide the order invoice informationincluding product data, merchant data and invoice data to the customerby: collecting the product data about the product including a productprice; collecting the merchant data including merchant identificationfor use in identifying merchant financial account information by thetransaction processing system; generating the order invoice informationincluding the product data, the merchant data, a total invoice amountfor payment by the customer and an invoice identification for use by atleast an accounting system of the merchant; receiving symbologyinformation in an aggregated barcode associated with the order invoice,the symbology information including at least a portion of the orderinvoice information encoded using a coding scheme of a barcode;providing an image of the aggregated barcode to the customer for use ingenerating a transaction request for settlement of the order invoice;and receiving a transaction response, the transaction response includingprocessing details of the transaction request by the processing system,the transaction response indicating transaction approval or transactiondenial of the order invoice.

A second aspect provided is a system including an order interface hostedon computer device for assisting ordering and payment processing of anorder invoice associated with a product selected by a customer, thecomputer device coupled to a transaction payment processing system overa communications network, the system comprising: a computer processorcoupled to a memory, wherein the computer processor is programmed toassemble order invoice information pertaining to the product and providethe order invoice information including product data, merchant data andinvoice data to the customer by: collecting the order invoiceinformation to include the product data about the product including aproduct price, the merchant data including merchant identification foruse in identifying merchant financial account information by thetransaction payment processing system, and invoice data including atotal invoice amount for payment by the customer and an invoiceidentification for use by at least an accounting system of the merchant;selecting unencoded data from the order invoice information and encodingthe unencoded data into symbology information using a coding scheme of abarcode; producing an aggregated barcode including the symbologyinformation, the aggregated barcode representing the order invoice; andsending the aggregated barcode for subsequent presentment as an image tothe customer for use by the customer in generating a transaction requestfor settlement of the order invoice.

A third aspect provided is a method for processing an order invoiceassociated with a product selected by a customer, the method comprising:collecting product data about the product including a product price;collecting merchant data including merchant identification for use inidentifying merchant financial account information by the transactionprocessing system; generating, using a computer processor, the orderinvoice information including the product data, the merchant data, atotal invoice amount for payment by the customer and an invoiceidentification for use by at least an accounting system of the merchant;receiving, using the computer processor, symbology information in anaggregated barcode associated with the order invoice, the symbologyinformation including at least a portion of the order invoiceinformation encoded using a coding scheme of a barcode; providing, usingthe computer processor, an image of the aggregated barcode to thecustomer for use in generating a transaction request for settlement ofthe order invoice; and receiving a transaction response, the transactionresponse including processing details of the transaction request by theprocessing system, the transaction response indicating transactionapproval or transaction denial of the order invoice.

A fourth aspect provided is a method for processing of an order invoiceassociated with a product selected by a customer, the method comprising:collecting the order invoice information to include product data aboutthe product including a product price, merchant data including merchantidentification for use in identifying merchant financial accountinformation, and invoice data including a total invoice amount forpayment by the customer and an invoice identification for use by atleast an accounting system of the merchant; selecting, using thecomputer processor, unencoded data from the order invoice informationand encoding the unencoded data into symbology information using acoding scheme of a barcode; producing, using the computer processor, anaggregated barcode including the symbology information, the aggregatedbarcode representing the order invoice; and sending the aggregatedbarcode for subsequent presentment as an image to the customer for useby the customer in generating a transaction request for settlement ofthe order invoice.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention will now be described inconjunction with the following drawings, by way of example only, inwhich:

FIG. 1 is a block diagram of components of a product ordering system;

FIG. 2 is block diagram of a merchant interface of FIG. 1;

FIG. 3 shows example encoded and unencoded information for the system ofFIG. 1;

FIG. 4 is an alternative embodiment of the merchant interface of FIG. 2;

FIG. 5 is a block diagram of a computer device implementing the merchantinterface of FIG. 1;

FIG. 6 is a block diagram of a computer device implementing the paymentapplication of FIG. 1; and

FIG. 7 is an example operation of the system of FIG. 1.

DESCRIPTION OF VARIOUS EMBODIMENTS

It will be appreciated that for simplicity and clarity of illustration,where considered appropriate, numerous specific details are set forth inorder to provide a thorough understanding of the exemplary embodimentsdescribed herein. However, it will be understood by those of ordinaryskill in the art that the embodiments described herein may be practicedwithout these specific details. In other instances, well-known methods,procedures and components have not been described in detail so as not toobscure the embodiments described herein. Furthermore, this descriptionis not to be considered as limiting the scope of the embodimentsdescribed herein in any way, but rather as merely describing theimplementations of various embodiments described herein.

The embodiments of the systems, devices and methods described herein maybe implemented in hardware or software, or a combination of both. Someof the embodiments described herein may be implemented in computerprograms executing on programmable computers, each computer comprisingat least one processor, a computer memory (including volatile andnon-volatile memory), at least one input device, and at least one outputdevice. For example, and without limitation, the programmable computercan be a mobile computing device having a processor for processingoptical machine readable images (e.g. barcode images) and program code,a server computer having a processor for generating barcodes based oninvoice information and processing program code, an image sensor forcapturing images, and at least one network interface for communicatingpayment transaction information and/or generated optical machinereadable images. Program code may be executed by the processor tooperate on input data, such as the captured image, to perform thefunctions described herein and generate output data representative oftransaction data. Further, program code may be executed by the processorto operate on input data, such as the invoice data provided by merchantproduct order systems for a plurality of products, to perform thefunctions described herein and generate output data as an opticalmachine readable image representing encoded invoice data.

Product Ordering System 10

Referring to FIG. 1, shown is a product ordering system 10 having amerchant order interface 15 hosted on a merchant computer device 17(e.g. a server) remotely coupled over a communications network 11 to acomputer device 12 of a customer 18. The order interface 15 of themerchant 16 can be a web site (hosted on the merchant computer device17) accessible over the communications network 11 by the customer 18using a browser operating on the computer device 12. Further, a paymentand transaction processing system 14 is connected via the communicationsnetwork 11 to the computer device 12 and the merchant order interface15. Accordingly, the order interface 15, computer device 12 andprocessing system 14 can interact (via network messages) together toinitiate and complete order and payment of products offered by themerchant 16 to the customer 18, such that an optical machine readableimage (OMRI) 200 (e.g. aggregated barcode) (see FIG. 3) is generatedduring the order process by the order interface 15. The OMRI 200 is usedby the product ordering system 10 to represent and facilitate processingof an order invoice 202 containing textual (e.g. unencoded) aggregatedinformation 201 (e.g. product pricing numbers, total invoice numbers,merchant 18 and/or customer 16 identification/account numbers, invoicenumbers, product descriptions and/or payment terms, etc.) that isencoded as symbology information 204 for a plurality of products,ordered by the customer 18 from the merchant 16 via the order interface15, as further described below. It is also recognized that theaggregated OMRI 200 can be used by the product ordering system 10 torepresent and facilitate processing of an order invoice 202 containingthe unencoded aggregated information 201 encoded as symbologyinformation 204 for at least one product ordered by the customer 18 fromthe merchant 16. Accordingly, processing of the order invoice 202involves the use of the optical machine readable image (OMRI) 200 thatcontains encoded invoice data, as further described below.

In a further embodiment (see FIG. 4), discussed below, the computerdevice 12 device does not necessarily have to communicate with the orderinterface 15 over the communications network 11, in order to receive theaggregated OMRI 200, however does interact with the order interface 15presented to the customer 18 on a merchant display screen and/or onprinted label at a merchant physical retail location. In this manner,the customer 18 can record an image of the aggregated OMRI 200 by usingan imager of the computer device 12 (e.g. a camera enabled mobiledevice), for subsequent processing by the computer device 12 and thetransaction processing system 14.

Definition of Products

In economics, economic output is divided into goods and services. Whenan economic activity yields a valuable or useful thing, it can be knownas production output of the totality of products (e.g. goods orservices) in an economy that the merchant 16 makes available for use bythe customers 18. Products as goods can range from a simple safety pin,food, clothing, computer components to complex machinery and electronicor physical media (physical or electronic versions of music, printmedia, etc.). Products as services are the performance of any duties orwork for another (e.g. helpful or professional activity) and can be usedto define intangible specialized economic activities such as but notlimited to: providing access to specific information; web services;transport; banking; legal advice; accounting advice; managementconsultant advice; and medical services. The merchant 16 providing theproducts can be a businessperson or individual engaged inwholesale/retail trade, an organization, an administration, and/or abusiness that sells, administers, maintains, charges for or otherwisemakes available product(s) that are desirable by the customers 18.Accordingly, the merchant 16 can be one person, or an association ofpersons, for the purpose of carrying on some enterprise or business; acorporation; a firm; etc. Further, it is recognised that the productscan be related to company activities not related to specific product(s),for example customer service, community activities, donations, and/orsponsorships. These general activities of the merchant 16 are alsoconsidered as part of the definition of merchant 16 products.

It is recognized that the merchant 16 products can include restaurantmeals (and/or service), such that the order invoice 202 represents ameal bill and the products are individual food and/or beverage items. Itis also recognized that the merchant 16 products can be groceries orother retail items being paid for in person by the customer 18 at themerchant retail establishment, for example.

Example Configuration of the Computer Devices 12,17

As further discussed, the merchant products are offered for sale via theorder interface 15 (i.e. online interface) that is accessible over thecommunications network 11. The order interface 15 provides the customer18 with the ability to select and/or specify a plurality of desiredproducts for purchase and also generates an aggregated OMRI 200 (seeFIG. 3) that contains encoded invoice information (the symbologyinformation 204) representing summary information (e.g. product listing,total purchase price, etc.) of the plurality of products, e.g. onebarcode representing invoice data for two or more products. In anyevent, it is recognized that the aggregated OMRI 200 is generated by theorder interface 15 to contain data (e.g. product data 206, merchant data208, customer data 211 and/or invoice data 210) of the order invoice 202pertaining to the plurality of products, including payment transactiondata needed by the processing system 14 to settle the financialtransaction (associated with the invoice data) by transferring fundsfrom a specified customer account to a specified merchant account. It isalso recognized that the order invoice 202 could contain order invoice202 data pertaining to only one product, as desired.

It is recognized that network 11 communication messages facilitating thecertain aspects of payment processing of the order invoice 202 arepreferably between a payment application 13 running on the computerdevice 12 and the processing system 14 (or the transaction interface 15and the payment processing system 14), rather than directly between thepayment application 13 and the transaction interface 15. The paymentapplication 13 can operate as a client of the processing system 14, suchthat the payment application 13 of the computer device 12 is registeredwith the processing system 14. It is also recognized that the merchantorder interface 15 can also operate as a client of the processing system14, such that the merchant order interface 15 of the computer device 12is registered with the processing system 14. Registration details (ofthe merchant 16 and/or the customer 18) can include financial accountinformation stored by the processing system 14.

Therefore, in one embodiment, in the event that the payment application13 needs (e.g. request) information from transaction interface 15relating to payment processing of the order invoice 202, these request(and response) network 11 messages would go through the paymentprocessing system 14 acting as an intermediary network interface betweenthe payment application 13 and the transaction interface 15. Therefore,in another embodiment, in the event that the transaction interface 15needs (e.g. request) information from the payment application 13relating to payment processing of the order invoice 202, these request(and response) network 11 messages would go through the processingsystem 14 acting as an intermediary network interface between thepayment application 13 and the transaction interface 15. However, it isrecognized that network 11 messaging pertaining to payment processingdirectly between the payment application 13 and the transactioninterface 15 can also be configured, for example for the purpose ofgathering information relevant to confirming the status of the paymentprocessing of the invoice order 202 (as implemented by the processingsystem 14), i.e. that that the customer 18 has indeed deposited fundsfrom an account 70 of the customer 18 into an account 72 of the merchant16 (as settled by the processing system 14).

Settlement pertaining to the order invoice 202 can be defined as where apayment amount is transferred from the account 70 of the customer 18 tothe account 72 of the merchant 16, i.e. the credit and debittransactions of the payment amount against the respective accounts 70,72 are either performed (e.g. in real time) or promised to be performed(e.g. included in a batch transaction to be performed later in the dayor following business day).

Barcode 200

The OMRI 200 (i.e. an optical machine-readable representation of data)representing order invoice 202 content contains symbology information204 in encoded form based on a coding scheme 209. One example of theOMRI 200 is a barcode, such that the coding scheme 209 is a barcodecoding scheme for use in encoding and decoding of the symbologyinformation 204 of the barcode. Another example of the OMRI 200 is adataglyph, such that the coding scheme 209 is a dataglyph coding schemefor use in encoding and decoding of the symbology information 204 of thedataglyph.

Referring again to FIG. 3, as used herein, the OMRI 200 (e.g. barcode,dataglyph, etc.) refers to an optical machine-readable representation ofencoded information or data, presented as an ordered pattern of symbols(i.e. symbology information 204). For example, barcodes can encodeinformation in the widths and the spacing of parallel lines, and may bereferred to as linear or 1D (1 dimensional) symbologies. Barcodes canalso encode information in patterns of squares, dots, hexagons and othergeometric shapes or symbols within images termed 2D (2 dimensional)matrix codes or symbologies. Typically, although 2D systems use symbolsother than bars, they are generally referred to as barcodes as well.Accordingly, barcode images discussed herein for use with a barcodescanner or decoder can refer to either 1D or 2D barcodes. Withconventional monochromatic barcodes, features are typically printed inblack on a white background, thereby forming a pattern that is used toform the machine-readable representation of invoice information of theorder invoice 202. With color barcodes, the pattern can include anynumber of colors (typically also including black and white)distinguishable from one another during the barcode decoding process.

The aggregated OMRI 200 is generated to include symbology information204 representing order invoice 202 content used to define product andpayment terms/details concerning the product(s) purchased by thecustomer 18 from the merchant 16 (see FIG. 1). As discussed furtherbelow, the aggregated OMRI 200 can be electronically displayed (e.g. ona computer display), can be provided as graphic content (e.g. an imagefile such as but not limited to a GIF or JPEG) in a network message)and/or can be provided in printed form (e.g. presented on a physicalmedium such as paper or plastic—for example associated with a picture ina magazine or present on a label). As discussed, interaction between theaggregated OMRI 200 and the customer 18 placing the order for thecollection of products can include customer 18 actions such as but notlimited to: selection (e.g. via mouse or other pointer) on a userinterface 104 of the customer device 12 displaying the aggregated OMRI200; receiving an image file containing the aggregated OMRI 200; and/orrecording/capturing the image of the aggregated OMRI 200 using an imager118 (e.g. camera) (see FIG. 6) of the computer device 12 (e.g. mobiledevice), such that the aggregated OMRI 200 is displayed on physicalmedia and/or electronic media (i.e. an electronic display adjacent tothe customer device 12 and in-range of the imager 118). Exampleenvironments of the described image capture process would be where theaggregated OMRI 200 is displayed on a desktop computer of the customer18 or on a computer terminal (part of the order interface 15) of themerchant 16.

In terms of the symbology information 204 of the aggregated OMRI 200,the symbology information 204 includes a plurality of symbols (i.e.graphical elements) that, as a collection of symbols or patterns (e.g.an organized collection of symbols forms a legend, or key), representsencoded invoice information that is distinct from the actual unencodedinvoice information 201 itself. For example, a graphical element (of thesymbology 204) of a black line of a specific width represents a textualelement (of the textual information 201) as the number six, while adifferent width represents a different textual element (of the textualinformation 201) such as the number two. It is recognized that graphicalelements can be pictures (e.g. images) of text elements and/or ofnon-text elements. For example, the graphical element “6” (e.g. encodedor symbology information 204) in the coding scheme 209 could be mappedto a product code “1234” (e.g. unencoded information 201). In anotherexample, the graphical element “(*)” (e.g. encoded or symbologyinformation 204) in the coding scheme 209 could be mapped to a productcode “1234” (e.g. unencoded information 201).

The purpose of the symbology information 204 is to communicate encodedinvoice information (that defines a plurality of invoice parameters) asreadable (e.g. decodable) by a decoder. The decoder could be present onthe customer device 12 and/or on the transaction payment processingsystem 14, as further described below. It is recognized that mapping(i.e. processing performed by the decoder or encoder) between thesymbology information 204 and the unencoded order invoice 202 data iswhat enables the aggregated OMRI 200 to be generated and interpreted. Aspecification of the symbology information 204 can include the encodingof the single digits/characters of the order invoice 202 textual data aswell as the start and stop markers into individual symbols (e.g. bars)and space between the symbols of the symbol collection/pattern, the sizeof a quiet zone required to be before and after the aggregated OMRI 200,as well as a computation of a checksum incorporated into the aggregatedOMRI 200 for error checking purposes as is known in the art.

It is recognized that the aggregated OMRI 200 do not contain descriptivedata, rather the aggregated OMRI 200 can be used as reference codes(e.g. decoded barcode information) that a computer uses to look up anassociated record that contains the descriptive unencoded order invoicedata 201, as well as any other relevant information about the productsor items associated with the order invoice 202 encoded in the aggregatedOMRI 200. For example, the matching item record of the symbologyinformation 204 can contain a description of the product, vendor name,product price, quantity-on-hand, etc., including any of the product data206, merchant data 208, customer data 211 and/or invoice data 210 asfurther described below. However, some OMRI 200 can contain, besidesreference ID, additional or supplemental information such as productname or manufacturer, for example, and some 2D OMRI 200 may contain evenmore information as they can be more informationally dense due thegreater variation potential of the printed patterns over those of 1DOMRI 200.

In terms of different barcode type, linear symbologies (e.g. UPCbarcodes as an example symbology format of the aggregated OMRI 200) canbe classified mainly by two properties, continuous vs. discrete andtwo-width vs. many-width. In continuous vs. discrete, characters (i.e.representing the invoice data content) in continuous symbologies usuallyabut, with one character ending with a space and the next beginning witha bar (e.g. light-dark patterns), or vice versa. Characters (i.e.representing the invoice data content) in discrete symbologies begin andend with bars and any intercharacter space is ignored as long as it isnot wide enough to look like the code ends. In two-width vs. many-width,bars and spaces in two-width symbologies are wide or narrow, and theexact width of a wide bar has no significance as long as the symbologyrequirements for wide bars are adhered to (usually two to three timeswider than a narrow bar). Bars and spaces in many-width symbologies areall multiples of a basic width called the module, wherein most suchcodes use four widths of 1, 2, 3 and 4 modules. Some linear symbologiesuse interleaving, such that the first character (i.e. representing theinvoice data content) is encoded using black bars of varying width. Thesecond character (i.e. representing the invoice data content) is thenencoded, by varying the width of the white spaces between these bars.Thus characters (i.e. representing the invoice data content) are encodedin pairs over the same section of the barcode. Stacked symbologiesrepeat a given linear symbology vertically.

In terms of multidimensional symbologies (e.g. 2D, 3D, etc.), the mostcommon among the many 2D symbologies are matrix codes, which featuresquare or dot-shaped modules (i.e. representing the invoice datacontent) arranged on a grid pattern. 2-D symbologies also come incircular and other patterns and may employ steganography, thereby hidingmodules within an image (for example, using DataGlyphs). Aztec Code isanother type of 2D barcode.

Quick Response Codes (QRC) is another a type of matrix barcode (ortwo-dimensional code) providing faster readability and larger storagecapacity compared to traditional UPC barcodes. The QR code (as anexample symbology format of the aggregated OMRI 200) consists of blackmodules arranged in a square pattern on a white background. Theinformation encoded can be made up of four standardized kinds (“modes”)of encoded data (e.g. numeric, alphanumeric, byte/binary, and/or Kanji),or by supported extensions virtually any kind of data.

It is also recognized that the symbology information 204 of the OMRI 200can include custom graphical elements (as codified in the coding scheme209) involving combinations of one or more graphical elements used torepresent a textual element, e.g. a corporate logo is used as acollection of graphical elements (e.g. circle, square, and company name)that is mapped (e.g. decoded) by the coding scheme 209 to represent atextual element (e.g. a URL to a webpage of the company website).Alternatively, the textual element can be mapped (e.g. encoded) by thecoding scheme 209 to represent the collection of graphical elements. Inthis example, the graphical element of a company name (the symbologyinformation 204) is decoded by the coding scheme 209 to represent thetext of the URL (the unencoded information 201). One example of barcodescontaining custom graphical elements is Microsoft™ Tag barcodes.

Microsoft™ Tags as an OMRI 200 are another type of barcode, e.g. 2Dbarcodes, which offer more flexibility than traditional barcode formatsboth in the barcode design and the content behind it. Because MicrosoftTag barcodes can be linked to data stored on a server, you can deliver amore robust online experience—including entire mobile sites—and updatethe content any time without having to change the Microsoft Tag. So, ifyou link a Microsoft Tag on your business card to your résumé, it willstill be valid after you get that big promotion. Microsoft Tags can beblack-and-white or full-color, including custom images (e.g., a companylogo). Therefore, the Microsoft Tag can have encoded data in thesymbology information 204 of the Tag that includes a link (e.g. URL) orother hyperlink that references a location in memory (e.g. in adatabase) and/or a network address where data content isavailable/accessible via the encoded link. In other words, a Tag encoderwould use a Tag coding scheme 209 to encode the unencoded linkinformation 201 into corresponding symbology information 204, e.g. thehyperlink to a website (the unencoded link information 201) would beencoded as one or more graphical elements such as a company logo or evengraphical elements (the symbology information 204) picturing the productitself.

It is also recognized that the symbology information 204 of theaggregated OMRI 200 can be encrypted (e.g. using a DES algorithm). Interms of the format of the symbology information 204, codewordsembedded/encoded in the symbology information 204 are typically 8 bitslong. It is recognized that the encoded order invoice 202 datarepresented by the symbology information 204 in the aggregated OMRI 200can be broken up into multiple blocks, such that each block includes anumber (e.g. 255) of codewords in length.

Another example of an optical machine-readable (e.g. OMRI 200)representation of encoded information or data are DataGlyphs, which area new technology for encoding machine readable data onto paper documentsor other physical media. They encode information into a number of tiny,individual glyph elements. Each graphical (e.g. glyph) element canconsist of a small 45 degree diagonal line as short as 1/100th of aninch or less, depending on the resolution of the printing and scanningthat is used, for example. Each glyph element (as the symbologyinformation 204) represents a single binary 0 or 1 (as the decodedinformation 201), depending on whether it slopes to the left or right.Sequences of these glyph elements (symbology information 204) can beused to encode numeric, textual or other information (unencodedinformation 201).

As an example configuration of the dataglyph symbology and coding scheme209, the individual glyphs are grouped together on the page (ordisplayed electronically on a display), where they form unobtrusive,evenly textured gray areas, like half-toned pictures. One of the reasonsfor using diagonal glyph elements is because research has shown that thepatterns that they form when massed together are not visuallydistracting. DataGlyph technology allows ordinary business documents tocarry thousands of characters of information hidden in these unobtrusivegray patterns that can appear as backgrounds, shading patterns orconventional graphic design elements. Often, their presence will gocompletely unnoticed. (The entire Gettysburg Address will fit in aDataGlyph about the size of a small US postage stamp). DataGlyph areascan be printed on a document as part of its normal printing process ordisplayed on a screen as part of the normal image rendering process. Theinformation to be put in the DataGlyphs is encoded as a sequence ofindividual glyphs, and these can be printed either directly by theencoding software (for instance, by computer laser printer) or via aconventional printing process, such as offset. The glyphs are laid downon a finely spaced rectangular grid so that the area is evenly textured.In addition, each glyph area contains an embedded synchronizationlattice or “skeleton”—a repeating, fixed pattern of glyphs which marksthe boundaries of the glyph area and serves as a clocking track toimprove the reliability of reading. Before data is placed into thesynchronization frame, it's grouped into blocks of a few dozen bytes anderror correcting code is added to each block. The amount of errorcorrection to be used is chosen by the application, depending on theexpected quality of the print-scan cycle. Higher levels of errorcorrection increase the size of the glyph area needed for a given amountof data, but improve the reliability with which the data can be readback. This can be very important in environments where there's a highlevel of image noise (for example, fax) or where the documents aresubjected to rough handling. As a final step, the bytes of data arerandomly dispersed across the glyph area, so that if any part of theglyph area on the paper is severely damaged, the damage to anyindividual block of data will be slight, and thus easy for the errorcorrecting code to recover. Together, error correction and randomizationprovide very high levels of reliability, even when the glyph area isimpaired by ink marks, staples and other kinds of image damage.

In view of the above description, it is recognized that OMRI 200 can beembodied as barcodes, dataglyphs or other images that contain encodedsymbology information 204 that can be decoded into unencoded information201 (e.g. textual elements) using an appropriate coding scheme 209 thatprovides a mapping (e.g. rules) between the symbology information 204 tointo the unencoded information 201 (e.g. the decoding process) and theunencoded information 201 into the symbology information 204 (e.g. theencoding process). In any event, the following description, forsimplified example explanation purposes only, refers to OMRI 200 asbarcodes 200. However, it is recognized that in the below description,the term barcode 200 can be interchanged with the broader meaning ofOMRI 200, as desired.

Payment Application 13

Referring to FIG. 1, it is recognized that the payment application 13can include a plurality of OMRI 200 related processing functionality, aplurality of transaction processing functionality and/or clientfunctionality configured for network 11 communication with a processingsystem 14 in a client-server relationship. For example, the paymentapplication 13 can be configured as a thin client of the processingsystem 14, such that the payment application 13 is configured tointeract with a OMRI processing system of the payment processing system14 via a series of web pages generated by the OMRI processing system,sent via network messages and displayed on the user interface 104.Accordingly, the payment application 13 would interact with a webbrowser (or other network communication program) to send and receive themessages via the network 11 containing payment processing specificinformation (e.g. settlement confirmation), i.e. to display the webpages on the user interface 104 including output data for the paymentprocessing and to coordinate the entry of input data on the userinterface 104 and network transmission of the input data for the paymentprocessing related to the order invoice 202.

Order Interface 15

The order interface 15 can be configured as a thick client of thebarcode generation capabilities (barcode generation module 62)processing system 14, such that the order interface 15 is provisionedwith transaction and/or barcode processing functionality similar to (orat least a portion of) that functionality of the barcode processingsystem and/or barcode generation system of the processing system 14, asfurther described below. It is recognized that the thick client versionof the order interface 15 could be configured to perform some of thebarcode processing on behalf of or otherwise in substitution of any ofthe processing functionality of the barcode processing/generation systemimplemented by the processing system 14 during processing of the orderinvoice data 202. It is also recognized that the thick client version ofthe order interface 15 could also be configured to communicate over thenetwork 11 via a series of web pages as generated or otherwise receivedby the order interface 15, sent as network messages between the computerdevice 17 and the processing system 14. It is also recognized that theorder interface 15 could request or otherwise obtain the barcodes 200pertaining to the order invoice 202 directly from the processing system14, i.e. operating as a thin client of the processing system 14, ratherthan directly generating the barcodes 200 using systems of the orderinterface 15 itself. In either case, the following description of thebarcode module 62 can be representative of the barcode generationcapabilities of the barcode module 62 of the order interface 15 and/orof the barcode module 62 of the processing system 14, as desired.

Referring to FIG. 2, shown is an example configuration of the orderinterface 15 that can include a network communications module 50 forreceiving order request messages 52 from the computer device 12 and forsending order response messages 54 to the computer device 12 over acommunication network 11. The communication network 11 can be a one ormore networks, for example such as but not limited to: the Internet; anextranet; and/or an intranet. Further, the communication network 11 canbe a wired or wireless network. It is also recognized that networkmessages 52,54 can be communicated between the computer device 12 andthe network communications module 50 via short range wirelesscommunication protocols such as but not limited to Bluetooth™, infrared(IR), radio frequency (RF), near field communication (NFC) and otherprotocols as desired.

The network communications module 50 can also be configured to send andreceive order confirmation messages 56 over the communications network11 with respect to the payment transaction processing system 14. Alsoincluded is a database 58 containing product data 206 (e.g. productpricing, product descriptions, product availability, etc.), merchantdata 208 (e.g. merchant bank account number, a unique merchant referenceID of the merchant assigned by the processing system 14, tax or merchantbusiness registration details), and network 11 address information ofthe payment transaction processing system 14. The database 58 can alsohave customized barcode definitions of a customized coding scheme 209containing relationships (e.g. rules) between machine readable symbologyand codewords used to encode (or decode) invoice information duringgeneration of the aggregated barcode 200 used to represent the orderinvoice 202.

For example, the customized coding scheme 209 can be used to encode(i.e. translate) unencoded (e.g. text based) invoice information 201 ofthe order invoice 202 into symbology information 204, performed duringgeneration of the aggregated barcode 200. The customized coding scheme209 can also be used to decode (i.e. interpret) symbology information204 present in the aggregated barcode 200 into unencoded invoiceinformation 201 of the order invoice 202 during processing of theaggregated barcode 200 (e.g. by the computer device 12 and/or theprocessing system 14). It is recognized that the customized codingscheme 209 is known to the processing system 14 (e.g. by its barcodegeneration module 62) and can include customized codewords pertaining tospecific invoice information such as but not limited to: merchant ID,customer ID; invoice amounts; invoice number; etc.

Referring again to FIG. 2, the order interface 15 also has an ordergeneration module 60 used to collect the order invoice 202 data (e.g.product data 206, merchant data 208, customer data 209 and/or invoicedata 210—see FIG. 3) for the plurality of products ordered/selected bythe customer 18 during interaction (e.g. online) with the orderinterface 15 via the computer device 12 (e.g. over the communicationsnetwork 11). It is recognized that product data 206 and some of thecustomer data 211 of the order invoice 202, such as specific productsordered and quantity of each product, could be provided to the ordergeneration module 60 obtained from order request messages 52 (e.g. viathe network communications module 50). Further, the order generationmodule 60 would collect (or otherwise receive) the merchant data 208 forthe order invoice 202 from the database 58 as well as pricinginformation (e.g. product data 206) of the ordered products. The ordergeneration module 60 also generates the invoice data 210 pertaining toproduct pricing total (optionally including applicable taxes) thatincludes the total invoice amount owed by the customer and merchantidentification information (associated with or otherwise embodying themerchant bank account information) of the order invoice 202. Forexample, in terms of the merchant bank account information, this couldbe supplied as part of the merchant information included in the orderinvoice 202 data or this could be supplied as a merchant identificationinformation (e.g. merchant ID) used by the processing system 14 tolookup the actual merchant bank account information known to theprocessing system 14 and therefore abstracted from the customer 18.

The order interface 15 has the barcode module 62 that can be configuredto use the available order invoice 202 data and the customized codingscheme 209 to generate the aggregated barcode 200. It is recognized thatthe aggregated barcode 200 can be generated by the barcode module 62 tocontain data of the order invoice 202 pertaining to the product(s)chosen by the customer 18, including payment transaction data needed bythe processing system 14 to settle the financial transaction (associatedwith the order invoice 202 data) by transferring funds from a specifiedaccount of the customer 18 to a specified account of the merchant 16. Inthis example, it is envisioned that the merchant 16 would preregisterwith the processing system 14 and be provided with a merchant ID that isassociated with the merchant's actual account information (and any othersensitive merchant information) stored in a secure database 9 of thetransaction processing system 14.

It is also envisioned as an alternative embodiment, that the barcodemodule 62 can be configured to not generate some or all of the barcodes200, rather send via request messages 57 the relevant data of the orderinvoice 202 (as collected by the order generation module 60) to theprocessing system 14. In response, the order interface 15 would receivevia the response messages 57 the generated barcode 200, for subsequentuse in providing the barcode 200 to the customer 18. In this case, thebarcode module 62 of the processing system 14 is the entity thatgenerates the barcodes 200 upon request of the order interface 15

Referring again to FIG. 2, the order interface 15 can also optionallyhave a barcode presentment module 63, used by the merchant 16 tophysically and/or electronically display the aggregated barcode 200 tothe customer 18, for example when ordering and payment of the merchantproducts are occurring at the point of sale (POS). The POS is defined asa checkout location where the order transaction is initiated andconfirmation of transaction acceptance or rejection is received, suchthat the merchant 16 is the business (bricks and mortar store orservice) that takes payment from the customer 18 for the merchant'sproducts. Therefore, it should be recognized that the order interface 15of the POS system can defined to include (or otherwise be associatedwith—e.g. in communication with via a local area network—not shown) aphysical POS terminal (e.g. an electronic cash register) in physicalproximity to the customer 18 at the time of product order and purchase.For example, the barcode presentment module 63 can be configured toprovide instructions to a printer for physically printing the aggregatedbarcode 200 and/or can be configured to provide instructions to anelectronic display for displaying the aggregated barcode 200. In eithercase, the barcode presentment module 63 is configured to present theaggregated barcode 200 to the customer 18 for subsequent image capture(of the aggregated barcode 200) using the customer's computer device 12(i.e. mobile device).

Encoding

One example of the customized coding interpretation scheme 209 forbarcodes is a modified UPC (Universal Product Code) to include invoicespecific data. Another example is a modified QR scheme, as furtherdescribed below. The numbers and/or letters (e.g. ASCII-AmericanStandard Code for Information Interchange) stored in the symbologyinformation 204 of the aggregated barcode 200 are unique identifiersrepresenting the particular standard code and custom code (representinginvoice specific data) defined in the customized coding scheme 209 that,when read by a barcode decoder, can be used to look up additionalinformation about the invoice item associated with the aggregatedbarcode 200. For example, the price, and optional description, of theproduct would be encoded in the aggregated barcode 200 using thesymbology information 204.

Accordingly, the barcode module 62 can take the order invoice 202 dataand uses the codes and associated rules of the customized codinginterpretation scheme 209 to convert a piece of the unencoded invoiceinformation 201 (for example, a letter, word, phrase, etc.) of the orderinvoice 202 data into another form or representation (one sign intoanother sign), not necessarily of the same type, i.e. the symbologyinformation 204. In information processing performed by the barcodegeneration module 62, encoding is the process by which textual invoiceinformation 201 of the order invoice 202 is converted into symbols (ofthe symbol format 204 defined by the customized coding scheme 209) to becommunicated. Decoding is the reverse process, converting these codesymbols 204 back into unencoded invoice information 201 understandableby a receiver. Therefore, the symbology information 204 generated fromthe unencoded invoice information 201 of the order invoice 202 data isused by the barcode generation module 62 to construct the aggregatedbarcode 200, according to the customized coding scheme 209. Thisaggregated barcode 200 is made available to the network communicationsmodule 50 to be sent in the order response message 54 (for example) tothe computer device 12 (e.g. displayed on a browser screen of the userinterface 104 of the computer device 12—see FIG. 6, delivered as animage file in the network message 54, etc.). It is recognized that theaggregated barcode 200 represents symbolically the unencoded data 201 ofthe order invoice 202.

Payment Processing Examples

The network communications module 50 is also configured to receiveconfirmation message(s) 56 from the processing system 14, for example asa result of interaction messages 56,64 between the computer device 12 ofthe customer 18 and the processing system 14, such that confirmationmessage(s) 56 include a confirmation that customer funds have been usedto pay the invoice amount (i.e. customer funds have been transferred—orpromised for transfer—from the customer account to the merchant accountin payment of the order invoice 202).

In one embodiment, the computer device 12 receives the aggregatedbarcode 200 from the order interface 15, processes the aggregatedbarcode 200 by at least selecting a mode of payment (e.g. specifying acredit card number, a debit card number, or any other accountinformation for use in paying the monetary amount of the invoice) andsends order invoice 202 data (e.g. invoice information 201 decoded fromthe symbology information 204 of the aggregated barcode 200, and/or atleast some of the symbology information 204 itself of the aggregatedbarcode 200) and account data pertaining to the selected mode of paymentto the processing system 14 as a transaction request 64 for paymentprocessing. The transaction processing system 14 then processes thereceived order invoice 202 information (e.g. received invoiceinformation 201 and/or invoice information 201 decoded by the processingsystem 14 from the received symbology information 204 of the aggregatedbarcode 200) contained in the transaction request 64 and sendsinstructions to the respective financial institutions (not shown), forexample, associated with the customer and merchant account informationto debit the customer account and credit the merchant account by theinvoice amount of the order invoice 202. The merchant confirmationmessage(s) 56 received by the order interface 15 could contain detailsof the payment processing including that the merchant account was (orwill be) credited by the invoice amount of the order invoice 202, aswell as any invoice data 210 identifying the order invoice 202 (e.g.invoice ID) for merchant accounting records. It is recognized that thecomputer device 12 would could also receive customer confirmationmessage(s) 56 contain details of the payment processing including thatthe customer account was (or will be) debited by the invoice amount ofthe order invoice 202, as well as any invoice data 210 identifying theorder invoice 202 (e.g. invoice ID) for customer accounting records.

In an alternative embodiment, the computer device 12 receives theaggregated barcode 200 from the order interface 15, processes theaggregated barcode 200 by at least selecting a mode of payment (e.g.specifying a credit card number, a debit card number, or any otheraccount information for use in paying the monetary amount of theinvoice) and sends order invoice 202 data (e.g. invoice information 201decoded from the symbology information 204 of the aggregated barcode200, and/or at least some of the symbology information 204 itself of theaggregated barcode 200) and account data pertaining to the selected modeof payment to the order interface 15 as a transaction request 64, forsubsequent forwarding as confirmation message(s) 56 by the orderinterface 15 to the processing system 14 for payment processing. Theprocessing system 14 then processes the received order invoice 202information (e.g. received textual invoice information 201 and/orinvoice information 201 decoded from the received symbology information204 of the aggregated barcode 200) contained in the confirmationmessage(s) 56 and sends instructions to the respective financialinstitutions (not shown), who can be part of or separate to theprocessing system 14. The financial institutions, for example based onthe received instructions from the processing system 14, uses thecustomer and merchant account information to debit the customer accountand credit the merchant account by the invoice amount of the orderinvoice 202. Subsequent confirmation message(s) 56 received by the orderinterface 15 could contain details of the payment processing includingthat the merchant account was (or will be) credited by the invoiceamount of the order invoice 202, as well as any invoice data 210identifying the order invoice 202 (e.g. invoice ID) for merchantaccounting records.

In is recognized in the above embodiments, that in terms of the customeraccount information, this could be supplied as specifically the customeraccount number or this could be supplied as customer identificationinformation (e.g. customer ID) used by the processing system 14 tolookup the actual customer bank account information known to theprocessing system 14 and therefore the customer account number would beabstracted from the merchant 18 and the general communications over thenetwork 11. In this example, it is envisioned that the customer 18 wouldpreregister with the processing system 14 and be provided with acustomer ID that is associated with the customer's actual accountinformation (and any other sensitive customer information) in a securedatabase 9 of the processing system 14.

Order Invoice Content

Referring again to FIGS. 1 and 3, the order invoice 202 is used by thecustomer 18 and the merchant 16 to define what has been purchased, when,by whom, from whom, and how much money has been spent on what. Theaggregated barcode 200 is generated to include the symbology information204 aggregating product invoice information 201 for two or more products(for example) as the order invoice 202, such that the symbologyinformation 204 of the aggregated barcode 200 encodes information 201 ofproduct data 206, merchant data 208, customer data 211 and/or invoicedata 210 of the order invoice 202. Therefore, the aggregated barcode 200represents the order invoice 202, using the symbology information 204,defined as a commercial contract issued by the merchant 16 to thecustomer 18, indicating the products, quantities, and/or agreed pricesfor products the merchant has (or will) provide the customer 18 inexchange for payment (i.e. debit of customer account and correspondingdebit of merchant account) of the order invoice 202. Further, the orderinvoice 202 indicates the customer 18 must pay the merchant 16,according to any payment terms contained in the order invoice 202. It isalso recognized that the order invoice 202 in a rental or professionalservices context could also include a specific reference to the durationof the time being billed, so rather than quantity, price and cost, theinvoicing amount can be based on quantity, price, cost and duration. Forexample, the rental/services order invoice 202 can refer to the actualtime (e.g. hours, days, weeks, months, etc.) being billed.

It is recognized that from the point of view of a merchant 16, the orderinvoice 202 can be regarded as a sales invoice. From the point of viewof the customer 18, the order invoice 202 can be regarded as a purchaseinvoice. The order invoice 202 can identify both the customer 18 and themerchant 16, but the term “invoice” generally refers to the fact thatmoney is owed or owing between the merchant 16 and customer 18.

For example, the product data 206 of the symbology information 204 caninclude for each product, information such as but not limited to: aproduct identifier (e.g. product number or code—such as a UPC code), aproduct purchase price (e.g. unit price of the product), a quantitynumber of the product (e.g. the number 2 in the case where two of thesame product in the purchase order); and/or a description of theproduct. The merchant data 208 of the symbology information 204 caninclude information such as but not limited to: name and contact detailsof the merchant; a bank account number of the merchant; a uniquemerchant reference ID of the merchant assigned by the processing system14; location of the merchant retail location; tax or merchantregistration details (e.g. tax number or business number such as a VAT(value added tax) identification number or a registration number for GSTpurposes in order to claim input tax credits) and/or indication ofwhether the purchase is an online or physical retail location purchase.The invoice data 210 of the symbology information 204 can includeinformation such as but not limited to: a unique invoice referencenumber (for use in tracking correspondence associated with the orderinvoice 202); date of the invoice; tax payments as a percentage of thepurchase price of the each of the products (e.g. GST or VAT); date (e.g.approximate) that the products were (or are to be) sent or delivered;purchase order number (or similar tracking numbers requested by thecustomer 18 to be mentioned on the order invoice 202); total amountcharged (optionally with breakdown of taxes) for the product(s); paymentterms (including method of payment, date of payment, and/or detailsabout charges for late payment); international customs information;shipping destination; and/or shipping origination location. It isrecognized that the data 206,208,210,211 of the symbology information204 is also represented in at least whole or in part in the textualinvoice information 201. In this manner, what symbology information 204in the aggregated barcode 200 can be decoded (by the computer device 12and/or the processing system 14) into the invoice information 201, andthe invoice information 201 can be encoded (by the order interface 15)into the symbology information 204.

In terms of customer data 211, this data of the symbology information204 can include information such as but not limited to: a reference codeto be passed along the transaction identifying the payer (e.g. customer18); name and contact details (e.g. address) of the customer 18; and/oran account number (e.g. a bank account number, a credit card number, adebit card number of the customer 18) identifying the source of funds tobe used to pay for the products. It is recognized that the accountnumber identifying the customer 18 source of funds to be used to pay forthe products, instead of being encoded in the symbology 204, can besupplied by the customer 18 using the user interface 104 of the customercomputer device, as further described below.

As discussed above, it is recognized that the customized coding scheme209 contains codewords and rules for use in translating (i.e. encoding,decoding) between the symbology information 204 of the aggregatedbarcode 200 and the invoice information 201 of the order invoice 202.

Further Embodiment of the Product Ordering System 10

Referring to FIG. 4, shown is an embodiment of the product orderingsystem 10 such that products are ordered by the customer 18 arespecified in person rather that electronically using network messages.For example, products can be scanned by a store clerk taken from acustomer shopping cart or can be food and/or beverage products orderedverbally at a restaurant.

In this embodiment, the computer device 12 is a mobile device that isnot connected (i.e. does not communicate via network messages) to theorder interface 15 by the network 11, rather the computer device 12 usesthe imager 118 (see FIG. 6) to capture an image of the aggregatedbarcode 200 (presented by the order interface 15 at the point of sale)for subsequent processing. In this case, it is recognized that the orderinterface 15 is in communication with the processing system 14 via thenetwork 11 and the computer device 12 is also in communication with theprocessing system 14 via the network 11, as described above with respectto the product ordering system 10 described in relation to FIG. 2.

Merchant Device 17

Referring to FIG. 5, the merchant device 15 can be a wireless-enabled(e.g. WiFi, WAN, etc.) personal data assistant, or email-enabledwireless telephone, for example a tablet. In addition, the wirelesscommunications are not limited to only facilitating transmission of textdata (e.g. encrypted) and can therefore be used to transmit image data,audio data or multimedia data, for example, as desired.

As shown in FIG. 5, the merchant device 17 comprises a communicationnetwork interface 102, a user interface 104, and a data processingsystem 106 in communication with the network interface 102 and the userinterface 104. The network interface 102 can include one or moreantennas for wireless communication over the communications network 11.The user interface 104 can comprise a data entry device (such askeyboard, microphone or writing tablet), and a display device (such asan LCD display).

The data processing system 106 includes a central processing unit (CPU)108, otherwise referred to as a computer processor, and a non-volatileor volatile memory storage device (e.g. DISC) 58 (such as a magneticdisc memory or electronic memory) and a read/write memory (RAM) 112 bothin communication with the CPU 108. The memory 58 includes data which,when loaded into the RAM, comprise processor instructions for the CPU108 which define memory objects for allowing the merchant device 17 tocommunicate with the computer device 12 and the processing system 14(e.g. one or more processing servers) over the communications network11. The instructions can be used to provide or otherwise host the orderinterface 15 as a website running on the merchant computer device 17 andaccessed via the network 11.

The CPU 108 is configured for execution of the order interface 15 (seeFIG. 2) for facilitating communication with the transaction processingsystem 14 and the computer device 12. For example, it is recognised thatthe order interface 15 is used to coordinate, as implemented by the CPU108, the generation, receipt, and processing of the invoice information201 and the symbology information 204 of the aggregated barcode 200.

The CPU 108 facilitates performance of the merchant device 17 configuredfor the intended task (e.g. of the respective module(s) of the orderinterface 15) through operation of the network interface 102, the userinterface 104 and other application programs/hardware (e.g. web browsermade available to the order interface 15) of the merchant device 17 byexecuting task related instructions. These task related instructions canbe provided by an operating system, and/or software applications locatedin memory, and/or by operability that is configured into theelectronic/digital circuitry of the processor(s) 108 designed to performthe specific task(s). Further, it is recognized that the deviceinfrastructure 106 can include the computer readable storage medium 58coupled to the processor 108 for providing instructions to the processor108 and/or to load/update the instructions. The computer readable medium58 can include hardware and/or software such as, by way of example only,memory cards such as flash memory or other solid-state memory. Thestorage 58 can also contain the customized coding interpretation scheme209 for use in encoding and/or decoding the aggregated barcode 200.

Further, it is recognized that the merchant device 17 can include theexecutable applications comprising code or machine readable instructionsfor implementing predetermined functions/operations including those ofan operating system and the modules 50,60,62,63, for example. Theprocessor 108 as used herein is a configured device and/or set ofmachine-readable instructions for performing operations as described byexample above, including those operations as performed by any or all ofthe modules 50,60,62,63. As used herein, the processor 108 may compriseany one or combination of, hardware, firmware, and/or software. Theprocessor 108 acts upon information by manipulating, analyzing,modifying, converting or transmitting information for use by anexecutable procedure or an information device, and/or by routing theinformation with respect to an output device. The processor 108 may useor comprise the capabilities of a controller or microprocessor, forexample.

Computer Device 12

Referring to FIG. 6, each computer device 12 can be a wireless-enabled(e.g. WiFi, WAN, etc.) personal data assistant, or email-enabledwireless telephone, or a desktop computer terminal. In addition, thewireless communications are not limited to only facilitatingtransmission of text data (e.g. encrypted) and can therefore be used totransmit image data, audio data or multimedia data, for example, asdesired.

As shown in FIG. 6, the computer device 12 comprises a communicationnetwork interface 102, a user interface 104, and a data processingsystem 106 in communication with the network interface 102 and the userinterface 104. The network interface 102 can include one or moreantennas for wireless communication over the communications network 11.Preferably, the user interface 104 comprises a data entry device (suchas keyboard, microphone or writing tablet), and a display device (suchas an LCD display). The display screen of the user interface 104 can beused to visually present a graphical user interface (GUI) of the paymentapplication 13 to the customer 18, including results of the barcode 200image capture process. The display screen can employ a touch screendisplay, in which case the customer 18 can manipulate (i.e. enter and/ormodify/delete) invoice information (e.g. product data 206, merchant data208, customer data 211 and/or invoice data 210) obtained as textualinvoice information 201 from the decoded aggregated barcode 200 and/oras supplemental information (e.g. customer data 211) added to thereceived invoice information 201 in order to generate the transactionrequest 64.

The data processing system 106 includes a central processing unit (CPU)108, otherwise referred to as a computer processor, and a non-volatilememory storage device (e.g. DISC) 110 (such as a magnetic disc memory orelectronic memory) and a read/write memory (RAM) 112 both incommunication with the CPU 108. The memory 110 includes data which, whenloaded into the RAM, comprise processor instructions for the CPU 108which define memory objects for allowing the computer device 12 tocommunicate with the merchant device 17 (for accessing the orderinterface 15) and the processing system 14 (e.g. one or more processingservers) over the communications network 11. The mobile device 12, andthe processor instructions for the CPU 108 will be discussed in greaterdetail below.

The CPU 108 is configured for execution of a payment application 13 forfacilitating communication between the transaction processing system 14and optionally the merchant device 17. For example, it is recognisedthat the payment application 13 is used to coordinate, as implemented bythe CPU 108, the generation, receipt, and processing of the aggregatedbarcode 200 and the transaction messages 64. For example, the paymentapplication 13 can operate the imager 118 and the encoder/decoder 120,as further described below.

The CPU 108 facilitates performance of the computer device 12 configuredfor the intended task (e.g. of the respective module(s) of the paymentapplication 13) through operation of the network interface 102, the userinterface 104 and other application programs/hardware (e.g. web browsermade available to the payment application 13) of the computer device 12by executing task related instructions. These task related instructionscan be provided by an operating system, and/or software applicationslocated in memory, and/or by operability that is configured into theelectronic/digital circuitry of the processor(s) 108 designed to performthe specific task(s). Further, it is recognized that the deviceinfrastructure 106 can include a computer readable storage medium 110coupled to the processor 108 for providing instructions to the processor108 and/or to load/update the instructions. The computer readable medium110 can include hardware and/or software such as, by way of exampleonly, memory cards such as flash memory or other solid-state memory.

Further, it is recognized that the computer device 12 can include theexecutable applications comprising code or machine readable instructionsfor implementing predetermined functions/operations including those ofan operating system, the imager 118, the decoder 120, and the paymentapplication 13, for example. The processor 108 as used herein is aconfigured device and/or set of machine-readable instructions forperforming operations as described by example above, including thoseoperations as performed by any or all of the imager 118, the decoder120, and the payment application 13. As used herein, the processor 108may comprise any one or combination of, hardware, firmware, and/orsoftware. The processor 108 acts upon information by manipulating,analyzing, modifying, converting or transmitting information for use byan executable procedure or an information device, and/or by routing theinformation with respect to an output device. The processor 108 may useor comprise the capabilities of a controller or microprocessor, forexample.

The data processing system 106 includes the imager 118 (e.g. a cameraincluding an image sensor—e.g. CCD or CMOS sensor) suitable forcapturing images of the aggregated barcode 200 displayed or otherwisepresented by the merchant 16 within range of the imager 118. The paymentapplication 13 is configured to control the operation of the imager 118to capture the image of the aggregated barcode 200, as well as tooperate the decoder to provide for decoding at least a portion of thesymbology information 204 into invoice information 201 for subsequentuse in generating the transaction request message 64 directed to theprocessing system 14. The storage 110 can also contain the customizedcoding interpretation scheme 209 for use in decoding the aggregatedbarcode 200.

Decoding

One example of the customized coding interpretation scheme 209 forbarcodes is modified UPC (Universal Product Code). The numbers and/orletters (e.g. ASCII-American Standard Code for Information Interchange)encoded in the barcode 200 are unique identifiers representing theparticular custom code defined in the customized coding scheme 209 that,when read by the barcode decoder 120, can be used to look up additionalinformation about the invoice item associated with the aggregatedbarcode 200. For example, the price and optionally description of theproduct would be stored in the aggregated barcode 200 using thesymbology information 204. The data could be decoded from the barcode200 and used to look up the price and description of the item from thecustomized coding scheme 209.

The decoder 120 circuitry and/or software is used to recognize and/or tomake sense of the symbology information 204 that make up barcode 200.The decoder 120 can translates symbols 204 into corresponding digitaloutput in a traditional data format (i.e. as invoice information 201).In order to decode the information in barcode 200, for example for 1Dbarcodes, the widths of the bars and spaces are recognized via edgedetection and their widths measured.

Operation of the Purchase Ordering System 10

Referring to FIGS. 1, 2 and 7, shown is an example operation 300 of theorder interface 15 of the merchant 16. The order interface 15 isconfigured for assisting ordering and payment processing of the orderinvoice 202 associated with one or more products selected by thecustomer 18.

At step 302, the order interface 15 (e.g. via the network module 50)collects product data 206 about the product including a product price,and merchant data 208 including merchant identification for use inidentifying merchant financial account information by the processingsystem 14.

At step 304, the order generation module 60 generates the order invoiceinformation including the product data 206, the merchant data 208, atotal invoice amount for payment by the customer 18 and an invoiceidentification for use by at least an accounting system of the merchant16. At step 306, the barcode module 62 either requests and receives(from the processing system 14) or generates the symbology information204 in an aggregated barcode 200 associated with the order invoice 202,the symbology information 204 including at least a portion of the orderinvoice information encoded using a coding scheme 209 of a barcode. Atstep 308, the barcode module 62, for example, provides an image of theaggregated barcode 200 to the customer 18 for use in generating thetransaction request 64 for settlement of the order invoice 202, andreceives at step 310 the transaction response 56 from the processingsystem 14 (for example), the transaction response 56 includingprocessing details of the transaction request 64 by the processingsystem 14, the transaction response 56 indicating transaction approvalor transaction denial of the order invoice 202.

While the exemplary embodiments have been described herein, it is to beunderstood that the invention is not limited to the disclosedembodiments. The invention is intended to cover various modificationsand equivalent arrangements included within the spirit and scope of theappended claims, and scope of the claims is to be accorded aninterpretation that encompasses all such modifications and equivalentstructures and functions.

We claim: 1-20. (canceled)
 21. A system for processing symbologyinformation of a barcode, the system comprising: a database includingmerchant financial account information stored in merchant profile datafor a plurality of merchants; a transaction processing system coupled tothe database and comprising a computer processor coupled to a memory,wherein the computer processor is programmed via a set of instructionsstored in the memory to process order information pertaining to aproduct of a merchant including product data and merchant data of themerchant by: receiving a transaction request including customeridentification and an image of the barcode directly from a mobile deviceof a customer without sending the transaction request to an orderinterface of the merchant, the image a result of scanning by the mobiledevice with an imager of the mobile device thereby creating the image ofthe barcode, the symbology information including at least a portion ofthe order information encoded using a coding scheme of the barcode, saidportion of the order information including the merchant data; decodingthe symbology information of said image to obtain the merchant data;comparing by the computer processor the merchant data obtained from saidimage to the merchant profile data in the database to identify themerchant financial account information of the merchant; and sending atransaction response to the order interface of the merchant, thetransaction response generated by the transaction processing systembased on the transaction request received directly from the mobiledevice, the transaction response including processing details of thetransaction request indicating a transaction approval or a transactiondenial of the order information, the processing details based on thecustomer identification matching customer financial account informationthat is withheld from the order interface of the merchant.
 22. Thesystem of claim 21, wherein said portion of the order informationincludes product prices and product identifiers aggregated for aplurality of products selected by the customer and the total invoiceamount of invoice data incorporates said product prices.
 23. The systemof claim 21, wherein said portion of the order information includespayment terms.
 24. The system of claim 22 further comprising the orderinterface coupled to a point of sale (POS) terminal with a display, suchthat the barcode is presented on the POS terminal for display on thedisplay, thereby providing for access to the barcode by the customerusing the imager.
 25. The system of claim 22 further comprising theorder interface coupled to a printer, such that the barcode is providedto the printer for printing of the barcode on a physical medium, therebyproviding for access to the barcode by the customer using the imager.26. The system of claim 22, wherein the product is selected from thegroup comprising: goods and services.
 27. The system of claim 26,wherein the order information relates a type of order selected from thegroup consisting of: a restaurant bill; a retail purchase either inperson or online; and a services agreement.
 28. The system of claim 27,wherein the merchant data is an abstracted version of the merchantfinancial account information, such that the transaction processingsystem is able to link the merchant data with the actual merchantfinancial account information stored by the transaction processingsystem.
 29. The system of claim 22, wherein the transaction approvalincludes customer identification information and indication of a fundstransfer to the merchant financial account satisfying the total invoiceamount.
 30. The system of claim 21, wherein said portion of the orderinvoice information includes a quantity of the product or a descriptionof the product.
 31. The system of claim 22, wherein the customeridentification is for use by the transaction processing system inaccessing actual customer financial account information duringprocessing of the transaction request.
 32. The system of claim 31,wherein the mobile device is configured to include invoice informationassociated with the barcode in the transaction request.
 33. A method forprocessing symbology information of a barcode having order informationpertaining to a product of a merchant including product data andmerchant data of the merchant, the method comprising: electronicallyreceiving a transaction request including customer identification and animage of the barcode directly from a mobile device of a customer withoutsending the transaction request to an order interface of the merchant,the image a result of scanning by the mobile device with an imager ofthe mobile device thereby creating the image of the barcode, thesymbology information including at least a portion of the orderinformation encoded using a coding scheme of the barcode, said portionof the order information including the merchant data; decoding thesymbology information of said image to obtain the merchant data;comparing by the computer processor the merchant data obtained from saidimage to the merchant profile data in a database to identify themerchant financial account information of the merchant, the databaseincluding merchant financial account information stored in merchantprofile data for a plurality of merchants; and sending a transactionresponse to the order interface of the merchant, the transactionresponse generated by the transaction processing system based on thetransaction request received directly from the mobile device, thetransaction response including processing details of the transactionrequest indicating a transaction approval or a transaction denial of theorder information, the processing details based on the customeridentification matching customer financial account information that iswithheld from the order interface of the merchant.
 34. The method ofclaim 33, wherein said portion of the order information includes productprices and product identifiers aggregated for a plurality of productsselected by the customer and the total amount of the data incorporatessaid product prices.
 35. The method of claim 34 further comprising thestep of providing the barcode on a point of sale (POS) terminal with adisplay for display on the display, thereby providing for access to thebarcode by the customer using the imager.
 36. The method of claim 34further comprising the step of providing the barcode on a printer forprinting of the barcode on a physical medium, thereby providing foraccess to the barcode by the customer using the imager.
 37. A method forprocessing symbology information of a barcode having order informationpertaining to product data of a merchant, the method comprising:electronically receiving a transaction request including customeridentification and at least a portion of the symbology informationdirectly from a mobile device of a customer without sending thetransaction request to an order interface of the merchant, the symbologyinformation a result of scanning by the mobile device with an imager ofthe mobile device thereby creating an image of the barcode, said atleast a portion of the symbology information encoded using a codingscheme of the barcode, said at least a portion of symbology informationincluding merchant data of the merchant; decoding said at least aportion of the symbology information to obtain the merchant data;comparing by the computer processor the merchant data obtained from saidat least a portion of the order information to the merchant profile datain a database to identify the merchant financial account information ofthe merchant, the database including merchant financial accountinformation stored in merchant profile data for a plurality ofmerchants; and sending a transaction response to the order interface ofthe merchant, the transaction response generated by the transactionprocessing system based on the transaction request received directlyfrom the mobile device, the transaction response including processingdetails of the transaction request indicating a transaction approval ora transaction denial of the order information, the processing detailsbased on the customer identification matching customer financial accountinformation that is withheld from the order interface of the merchant.38. A method for processing symbology information of a barcode havingorder information pertaining to product data of a merchant, the methodstored on a computer readable medium for execution by a computerprocessor to perform: scanning by a mobile device with an imager of themobile device thereby creating an image of the barcode including thesymbology information, at least a portion of the symbology informationencoded using a coding scheme of the barcode, said at least a portion ofsymbology information including merchant data of the merchant;electronically sending a transaction request to a transaction processingsystem including customer identification and said at least a portion ofthe symbology information directly from the mobile device of a customerwithout sending the transaction request to an order interface of themerchant; receiving a transaction response from the transactionprocessing system by the mobile device, the transaction responsegenerated by the transaction processing system based on the transactionrequest received directly from the mobile device, the transactionresponse including processing details of the transaction requestindicating a transaction approval or a transaction denial of the orderinformation, the processing details based on the customer identificationmatching customer financial account information that is withheld fromthe order interface of the merchant and based on merchant financialaccount information of the merchant that is withheld from the mobiledevice; wherein the transaction processing system obtained the merchantfinancial account information by decoding said at least a portion of thesymbology information to obtain the merchant data, compared the merchantdata to merchant profile data for a plurality of merchants stored in adatabase to identify the merchant financial account information of themerchant.